1. Field of the Invention
This invention relates to adapters for use with an enterprise information system (EIS) and more particularly relates to abstracting metadata of various different formats into a common format for use by an EIS.
2. Description of the Related Art
Adapters allow business events to flow from an enterprise information system (EIS) to a listening client such as a business process or other application. The Java 2 Enterprise Edition (J2EE) standard defines a standard approach to building these adapters as outlined in the J2EE connector architecture (JCA) specification.
Advanced implementations of adapters are metadata-driven. This implies that the adapter is not hard-coded for each object type in the system, but rather has a form of discovery in which a representation of the object (metadata) in the EIS is constructed at build time such that at runtime the adapter uses this metadata, along with the object data, to process the object. In most implementations, metadata is in a pre-existing format, such as a standardized EIS schema. Standardized metadata includes such information as property name, property type, maximum length, cardinality, and anything else that can be described in a standard schema. Metadata may also be in a format defined by the adapter. This form of metadata is called Application Specific Information, or ASI.
ASI can typically occur in three forms: object level metadata; operation level metadata; and property level metadata. Object level metadata includes the information about what type is being processed. Operation level metadata is context-specific object metadata that is valid for the operation being processed at the present time. Property level metadata is information about a particular property in an EIS schema such as a column name as it occurs in the EIS which may be different than the property name in the object. Generally, this ASI data is structured such that it may be described as a Map (table), or Map of Maps (tree).
Conventional adapters may also have the capability to handle data in multiple end formats depending on the runtime system they are running in. This is accomplished via a Data Exchange API. In some embodiments, the Data Exchange API allows the adapter to interact with data, such as by reading or writing a particular value, through a set of interfaces known as a Data Exchange Service Provider Interface (DESPI). These interfaces are implemented by the runtime in which the adapter is running in order to allow the adapter to deal with the runtime's data format instead of the runtime having to convert the adapter's data format to its own. For instance, if a J2EE application deals with data in the JavaBean format, a Data Exchange implementation for JavaBean will read and write to the bean on behalf of the adapter. The same is true for other data formats such as Service Data Ojects (SDO). In effect, the DESPI makes the incoming data format received by the adapter “pluggable”.
However, even though conventional technologies such as a DESPI allow the handling of multiple data formats, such technologies do not address how to “plug-in” multiple different formats for metadata. For example, an adapter is typically concerned with certain metadata information or ASI such as type information, facets such as “maximum length”, cardinality of children, and annotations. In conventional systems ASI is used to drive the adapter which means that the specific adapter code is embedded with and depends on the ASI. Therefore, in order to support more than one metadata format, it is critical to provide an abstraction of pertinent metadata information from incoming objects into a form compatible with the adapter code. Thus, by providing an interface for abstracting pertinent metadata from a variety of different metadata formats, it becomes possible to overcome some or all of the current needs in the art.